Business Analyst Community & Resources | Modern Analyst

What does "Digital Twin" refer to?

Adrian M. — Tue, 15 Apr 2025 04:11:00 GMT

A “Digital Twin” is a virtual representation or simulation of a physical entity, process, or system. This concept involves the creation of a dynamic, data-driven model that mirrors its real-world counterpart in terms of behavior, condition, and context. The model is continuously updated with live data—often through sensors, IoT devices, or other real-time data feeds—allowing it to replicate changes and events happening in the physical environment.

By establishing this digital reflection, organizations gain a powerful tool for monitoring, analysis, and optimization. For instance, a digital twin of a manufacturing assembly line can capture data on throughput, machine performance, and environmental factors like temperature or humidity. Analysts can then simulate various scenarios—such as equipment failures or resource shortages—to see how they would impact production, without risking disruptions in the actual facility. This approach fosters proactive decision-making, enabling companies to identify potential bottlenecks, predict failures, and schedule maintenance before a critical issue arises.

One of the key benefits of digital twins is cost savings and risk mitigation. Rather than running trials in the physical world—which can be expensive, time-consuming, or even dangerous—organizations can safely test ideas in the virtual environment. This streamlines innovation, encourages rapid prototyping, and reduces the likelihood of costly mistakes. Furthermore, by harnessing real-time data, the digital twin can provide immediate visibility into inefficiencies and highlight opportunities for improvement. This continuous feedback loop helps businesses refine processes and optimize performance over time.

For a Business Analyst, digital twins open up new avenues for requirements gathering, stakeholder alignment, and strategic planning. By interacting with the digital replica, analysts can better understand current operations, validate assumptions, and propose data-driven recommendations. They are also equipped to convey complex operational insights to non-technical stakeholders, illustrating how suggested changes may play out in reality. Ultimately, digital twins bridge the gap between physical operations and digital insights, offering a holistic lens through which an organization can monitor, analyze, and refine its products, processes, or systems.

What is a Flowchart Diagram?

Adrian M. — Mon, 10 Oct 2022 22:52:00 GMT

A flowchart diagram or just flowchart is a term generically used to refer to a diagram which shows the flow of a process (step by step). More specifically a flowchart refers to a very specific type of structured workflow diagram which has been adopted by the International Organization of Standardization (ISO) and updated in 1985 with ISO 5807.

The flowchart is very similar in uses and functions as the UML activity diagram and the BPMN process diagram.

The flowchart diagram is drawn using a set of standard flowchart symbols including:

Symbol Name	Visual Depiction	Description
Flow line		The flowline represents the standard connector of the rest of the symbols in a flowchart. It is terminated with an arrow to show the direction of the flow/process (generally top to bottom or left to right).
Terminal		This flowchart symbol represents either the beginning of the flow or the end of the flow. A flowchart should have only one beginning symbol.
Process		The process flowchart symbol represents an action or activity which takes place at the given step in the process. Generally used to depic an action which takes place in the system or which uses the system.
Predefined Process		The flowchart pre-defined process symbol depicts the fact that this step is decomposed in detail in a different diagram or page. If a given sub-process or segment of a process is reused, it can be defined once and then specified again using the pre-defined process symbol.
Decision		The flowchart decision symbol is very similar to the decision symbol of other diagraming techniques and issued to show where a given process or flow can split into two or more branches based on a decision condition.
Input or Output		This flowchart symbol depicts that at this point in the flow data is either entred into the process/system or data is being output from the process/system.
Manual Input		The manual input flowchart symbol is used to show that a human is performing data entry or providing information to the system.
Data file or Database		The database flowchart symbol is used to depict storage of data (it could be a database, a file, etc.) and it could be used either to read data from or write data to.
Document		The document flowchart symbol represents a single document (ex: PDF, Word, etc.) used within the flow being documented. If multiple documents are used, multiple document symbols can be overimposed and slightly offset.
Manual Operation		The manual operation flowchart symbol is used to show that a user performs a manual operation within the flow which is other than simply data input.
On-page Connector		When a flowchart becomes too complicated and flowlines cross each other, an on-page connector can be used to show where to connect next without crossing lines.
Off-page Connector		When a flowchart becomes too large to fit on one page, the off-page connector symbol can be used to show where the flow leaves off on one page and then where it picks-up on a different page.
Initialization		The initialization symbol represents a step in the process (generally at the beginning) where a certain system routing or processed needs perform preparation/initialization activities.

When to use a Flowchart

Flowcharts are helpful whenever the problem domain you are tackling involves process or workflow or whenever you are trying to depict a structured step-by-step process.

Some example instances when a flowchart would be beneficial:

Document the “as-is” or “to-be” business processes.
Depict the logical flow of an algorithm which needs to be implemented.
Show how a user can interact with a system to achieve a desired objective.
Define the workflow for a given manual activity.

Alternative to Flowcharts

Since the advent of the flowchart, new modeling techniques and standards have been created and which, in many cases, have become more popular than the flowcharts, such as:

Data Flow Diagram
UML Activity Diagram
BPMN Process Flow Diagram
etc.

Example Flowchart

What is Scope Creep and how do you manage it?

Chris Adams — Mon, 10 Oct 2022 17:30:00 GMT

Scope creep occurs when additional features are slipped into a project after the project scope is defined and the project has started. The intent is generally good with the hope of making the delivered product better, but these changes can lead to the project running over time and/or over budget. How you manage scope creep depends on the type of project.

Agile: User Stories versus Epics, what's the difference?

Chris Adams — Fri, 10 Jun 2022 16:00:00 GMT

User Stories and Epics make up the essential building blocks of agile planning and development. They are closely related and, therefore, the differences are often misunderstood.

Describe the User Centered Design methodology

Chris Adams — Sun, 13 Mar 2022 17:42:00 GMT

The User Centered Design methodology focuses on the user's needs and goals throughout the entire product or application development lifecycle. This design approach places the user as the focal point of all phases of the development process from concept development to design, development, deployment, and finally to post-deployment assessment. It is an approach which emphasizes cognitive factors such as a user’s perception, emotion, and memory and how these cognitive factors participate in the interactive experience.

What is 8-Omega?

Chris Adams — Sun, 06 Dec 2020 19:05:00 GMT

8-Omega a business change framework conceived to aid organizations in the transformation and improvement of their business processes. 8-Omega addresses 4 key perspectives: Strategy, People, Process, Technology.

Additionally, 8-Omega transitions through 8 stages or lifecycle phases, hence its name. Each of the 4 key perspectives is considered throughout every stage or lifecycle phase. These phases are: Discover, Analyze, Design, Integrate, Implement, Manage, Control, Improve

List the steps you would take to bring a product from idea to deployment and beyond.

Chris Adams — Sun, 08 Nov 2020 20:14:00 GMT

Some of these steps could be combined, pared down, or avoided altogether depending on the demands of the project and complexity of the product or application. Use the minimum amount of tools, models, and specifications needed to communicate the necessary information to the coders in a way that ensures the final product meets the expectations of the customer and is defect free. Once might refer to this as “just enough documentation” – not too much, but not too little.

What is the PDCA method and how is its application by the Business Analyst beneficial?

Chris Adams — Fri, 06 Mar 2020 17:50:00 GMT

PDCA is a 4-step, iterative method commonly used for Business Process Improvement. PDCA stands for Plan, Do, Check, Act.

What is an Agile Mindset?

Chris Adams — Sun, 08 Dec 2019 21:31:00 GMT

Agile is a term that was first coined in 2001 with the creation of the Agile Manifesto. Agile has grown enormously in the last two decades and is now used by thousands of organizations and teams around the world. With that growth in popularity many variations have emerged – new frameworks like Kanban and SAFe have been created and thousands of books have been written on different elements of Agile.

What is Program Increment Planning as it applies to the Scaled Agile Framework?

Chris Adams — Mon, 11 Nov 2019 18:34:00 GMT

Program Increment (PI) Planning is one of the biggest and most important events in the Scaled Agile Framework (SAFe). It aims to set the direction and activities for the Release Train’s next 8-12 weeks of work through a large scale planning session. To understand PI Planning properly we need to first take a step back and understand three key terms; SAFe, Agile Release Trains and Program Increments.

What is a Sprint in Scrum/Agile?

Chris Adams — Mon, 11 Nov 2019 17:28:00 GMT

A sprint is a short, defined period of time that a team uses to organize their work cycles - it is the key feature of Scrum (the most popular Agile framework) and is used by thousands of teams around the world.

Sprints last between one and four weeks, but two week long sprints are the most common. Throughout this article I’m going to refer to two week long sprints for the sake of simplicity.

Sprints start with defining the goal and scope. This shouldn’t change during the sprint, once it has been defined. The team then go about completing the tasks of the sprint. By the end of the sprint the aim is for the team to have completed everything to achieve their goal.

How do you define Agile?

Chris Adams — Sun, 07 Jul 2019 15:50:00 GMT

Agile is a general term and conceptual framework used to describe a number of “light-weight” methodologies, such as Extreme Programming (XP), SCRUM, and Rapid Application Development (RAD), which exhibit a series of common characteristics.

What is Water-Scrum-Fall?

Chris Adams — Sun, 10 Mar 2019 20:43:00 GMT

Water-Scrum-Fall is a term first coined by Forrester to describe the reality of the current state of Agile as it exists in many organizations today. It's hybrid approach to application lifecycle management that combines elements of both Waterfall and Scrum development methodologies.

What is DevOps and how does it relate to software development?

Chris Adams — Sun, 10 Mar 2019 16:42:00 GMT

As the name suggests, DevOps represents a union of two different sub-disciplines – Development and Operations. Most analysts are highly familiar with the Development portion of DevOps. This is the traditional software development lifecycle used to create or make major changes to software applications. It includes a vast network of people who assist in developing a product including product managers, business analysts, software developers, quality assurance engineers, and others. From the DevOps perspective, this stage end just prior to software release/deployment.

The Operations portion of DevOps tend to be less familiar to analysts. In years past Development and Operations operated almost entirely in their own silos. The Ops team is made up of system and network engineers, DBAs, and others that build, manage, and monitor the IT infrastructure required to ensure the software can be properly deployed and supported. They receive the tested software builds and manage the release and deployment of the software onto the IT network while monitoring network stability.

What is a canary release and what are some of the benefits?

Chris Adams — Sun, 13 May 2018 23:48:00 GMT

A canary release is a technique used to mitigate the risk associated with rolling out new code and functionality to everyone by making the new release only available to a small group of end users. Due to the smaller size of the user group, the impact of the new release is relatively small. If it's determined that bugs exist or that the new functionality or new design isn't well received then it's easy to rollback.

What is a Minimum Viable Product?

Chris Adams — Mon, 12 Mar 2018 17:05:00 GMT

A Minimum Viable Product (MVP) refers to a product that has just enough features to reasonably demonstrate its viability to a group of stakeholders in order to receive feedback. By greatly limiting the scope of the product to its absolute minimum feature set the product development team is able to limits costs and risks.

Describe the Six Sigma methodology?

Chris Adams — Sun, 10 Dec 2017 20:55:00 GMT

Six Sigma is a process improvement methodology. It is structured into 5 phases which can be iterated to continually improve key processes and deliver greater efficiencies and success within an organization. These 5 phases are Define, Measure, Analyze, Improve, and Control expressed as the acronym DMAIC (pronounced dee-may-ic). Six Sigma, being a process improvement methodology, views the entire world in terms of processes—processes that achieve goals, processes that act on data, etc.

Six Sigma DMAIC versus DMADV, what’s the difference?

Chris Adams — Sun, 10 Dec 2017 20:50:00 GMT

The Six Sigma process improvement methodology defines the DMAIC and DMADV acronyms as follows.

DMAIC stands for Define, Measure, Analyze, Improve, Control. These 5 steps are used for improvement of existing processes to identify a candidate process, understand its current state of effectiveness, improve on the process, and manage its continued performance. This is described in more details under Describe the Six Sigma Methodology.

DMADV stands for Define, Measure, Analyze, Design, Verify. These 5 steps are used when a process doesn’t yet exist and needs to be designed to ensure it will meet customer specifications. It is also intended to be used when an existing process cannot be improved enough to bring it to within customer specifications and needs to be completely redesigned.

Describe the life cycle of a User Story?

Chris Adams — Mon, 09 Oct 2017 15:20:00 GMT

User Stories are used by agile methodologies to capture the functionality that a system or software should support. For details about what a user story is and how to write one reference What are User Stories.

Which is better: Waterfall or Spiral development?

Chris Adams — Mon, 15 May 2017 11:30:00 GMT

The choice of SDLC methodology for a project largely depends on: (1) the type of project, and (2) the environment or organizational culture within the project takes place. With that said, a Spiral method is superior for the vast majority of projects today, especially those which include the development of customer facing products.

What types of actions can help the business analyst avoid Analysis Paralysis?

Chris Adams — Sun, 12 Feb 2017 22:10:00 GMT

Analysis Paralysis is the dreaded black hole of projects. So, how do you recognize that you might be in Analysis Paralysis. Here are a few symptoms that might clue you in.

How can the acronym INVEST assist the analyst during the development of user stories?

Chris Adams — Sun, 12 Feb 2017 11:56:00 GMT

INVEST is an acronym that can help a Product Manager or Developer create quality user stories. INVEST stands for Independent, Negotiable, Valuable, Estimable, Sized-Appropriately, Testable.

I - Independent: The user story should be self-contained if at all possible to avoid dependencies on other user stories. Since one characteristic of agile methodologies is the ability to be flexible and re-prioritize what’s important, independent user stories allow for flexibility during iteration planning. If you do find that your user stories are dependent upon one another, you may be able to combine smaller user stories together that have a dependency between one another. Similarly, you can divide larger dependent user stories into smaller stories such that one of the new smaller stories contains and isolates the overlapping portion of the larger stories.

N - Negotiable: User stories can always be changed or rewritten up until the point of coding. This further supports the flexibility associated with agile methodologies. Since requirements often evolve or rise and fall in priority, user stories should be able to adapt with the changing requirements.

V - Valuable: A user story represents a goal of an end user or purchaser and should deliver functionality that is deemed valuable. This means that specifics of the technical design are not something that you would document as user stories. However, some technical requirements have a component which is valuable to a user. A user might expect pages to load within 2 seconds. The user story would specify the need for 2 second page load times while the specifics of the physical implementation of this would be left out.

E - Estimable: You should always be able to estimate the size of a user story. Sometimes, developers won’t have the experience required to size a particular situation or needed for a user story. When this occurs the user story can be split into two separate user stories. The first is a “spike” which is where developers do some quick research to determine the feasibility of something or get a better idea of how long it might take to implement the particular feature. The spike is always time-boxed, meaning it is limited to a pre-defined amount of time. The “spike” user story might be named “Research (something) to determine…)”, while the second user story is where the functionality will actually be delivered. These two user stories should be scheduled into two separate iterations such than the spike can be completed and the feasibility of the second user story assessed before coding begins. This gives the team time to react if problems arise from the spike.

S - Sized Appropriately: User stories shouldn’t be too big or too small. So how do you decide what size is right. First, any user story that can’t be completed by a developer within a single iteration (or by a developer pair when paired programming is being used) is too big. The user story should be subdivided into two or more smaller stories. Similarly, there is no need to make user stories too granular just for the sake of decomposing features. If features group well together and complement each other then it makes sense to make a single user story. For instance, “As a job seeker I want to be able to add, delete, and edit a job skill on my electronic resume so that I can maintain an accurate listing of my skills.” There is no reason to split “add, delete, and edit” into multiple user stories unless one of them creates a significant amount of work that would make the user story too large for the iteration.

T - Testable: User stories must be testable in order to ensure that development is complete and has been done correctly. So when are user stories not-testable? Often, if the analyst isn’t carful, non-functionality requirements are written in a manner which is un-testable. Consider the example, “pages should always load quickly”. There are two un-testable components of this statement; “always” and “quickly”. A testable statement would be “pages should load within 1.5 seconds 97% of the time”.

--
Chris Adams
LinkedIn Profile

What is Value Stream Mapping and how is it performed?

Chris Adams — Sun, 10 Apr 2016 16:38:00 GMT

Value stream mapping originated in the manufacturing industry and was used to optimize manufacturing processes. It is often applied as part of the Six Sigma methodology. Since then value stream mapping has just as effectively been used to optimize business and system processes.

Value stream mapping looks at the suppliers and customers of a process, the information and materials used and created (including queues and inventories), and process times of activities. In a business environment, the suppliers and customers can be business workers, part of an organization, or another company while the material and information is business information and documents.

What is a Daily Scrum Meeting?

Chris Adams — Sun, 07 Feb 2016 17:50:00 GMT

The Daily Scrum Meeting, sometimes also called a Daily Standup Meeting, is a brief status meeting where a team (ideally around 6-9 members) meets and updates one another on the work that has been completed and what will be completed next. It provides an update to the entire team while providing a daily refocus for each team member as they deliver their status.

What is a Burn Up Chart and how does it differ from a Burn Down Chart?

Chris Adams — Sun, 10 Jan 2016 22:49:00 GMT

A Burn Up Chart is a tool used to track how much work has been completed, and show the total amount of work for a project or iteration. It’s used by multiple software engineering methods but these charts are particularly popular in Agile and Scrum software project management. The completed work and total work is shown on the vertical axis in whatever units a project team feels works best, i.e., work-hours, work-days, story points, or any other work unit. The horizontal access displays time, usually in days, weeks, or iterations (sprints).

How do you avoid requirement conflicts while making changes to an existing system where no documentation exists?

Chris Adams — Sun, 13 Dec 2015 20:41:00 GMT

Companies with small IT departments or analysis teams often lack a well defined analysis process. It's not uncommon for analysts to be hired onto a team and find that they are being asked to assist with requirements and new features for a system where no documentation exists. In this case, the analyst needs to create a minimal amount of documentation retroactively.

What are User Stories?

Chris Adams — Sun, 13 Dec 2015 16:00:00 GMT

Extreme Programming (XP), one of many Agile methods, introduced the practice of User Stories to describe what a system or piece of software should do. User stories have since been adopted by many of the agile methods used today.

User Stories are short descriptions of functionality that will be valuable to a user or purchaser of the software or application. They describe the users’ goals when using the system. The initial descriptions can be written by the users, customers, product managers, or developers, and are just a few sentences at most (1-3 sentences being typical). This isn’t the entire user story, but it is all that is created at first.

The development of user stories occurs in three parts; the Card, the Conversation, and the Confirmation.

The Card: Named for the standard index cards on which a user story is often captured, Cards include the brief description of the user story, its relative size to other user stories (called story points), and the priority of the functionality. The cards are used for planning the work that will be completed during each iteration of development. If the size of the user story gets too big to complete within a single iteration then it should be broken into smaller stories. The term used to describe a user story which needs to be further broken down into smaller stories is an “Epic”.
The Conversation: While the conversation itself is not an actual deliverable, it is a critical step in the user story development process. Discussions about each user story are had with the users/customers of the system to flesh out details. The details of the conversations are documented in the form of acceptance tests called “The Confirmation”.
The Confirmation: Acceptance tests are details which are captured from the Conversation that can be used to verify that the user story has been successfully implemented. When index cards are used, the acceptance tests are typically written on the back of the card itself. Acceptance tests can and should be captured whenever they are thought of, however, at the beginning of each iteration there is a defined period of time which is set aside to generate acceptance tests.

Using these three parts, the goal of the user story is to plan which functionality will be developed during each iteration, provide enough detail that a developer pretty much understands what needs to be coded, and provide a means to verify that they have achieved the goal. If the developer needs more details, more conversations are had, the details of which are documented as more acceptance tests.

Here are some sample user stories (the Card) for a job board:

I want to post a resume
I want to search for a job
I want to electronically submit my resume for jobs I like

Some user stories follow a more formal structure than others. One formal approach suggested by Mike Cohn follows the structure: “As a (role) I want (something) so that (benefit)”. At first, structuring your user story descriptions like this may seem like overkill sometimes, but it makes sure that you aren’t forgetting WHO you are designing the functionality for and WHY.

As a job seeker I want to post my resume so that recruiters and employers can find it.
As a job seeker I want to search for a job so that I’m in control of my job search.
As a job seeker I want to electronically submit my resume for jobs I like so that I increase the changes of receiving an interview.

Here are some acceptance tests for the user story, “I want to search for a job”

Test with keyword, salary, and location search parameters
Test that the search results are returned in 2 seconds or less

Some comparisons can be made between user stories and use cases, but there are key differences that should be remembered.

Size and Scope	User Stories have limited scope to fit within an iteration.	Use Cases are almost always larger in scope than user stories.
Structure	User Stories typically represent a single scenario or path through a use case. This could be the main scenario, or an alternative or extension path. Remember that the user story includes the acceptance tests which often describe the details covered in alternative and extension flows.	Use Cases represent a series of related user scenarios. While a main scenario (often the most common scenario) is selected, there are many decision points throughout the flow that branch into alternative or exception flows.
Purpose	User Stories are created to facilitate conversation between the client and development team when the time is right, and have the primary purpose of supporting release and iteration planning process. They are never referred back to as a contract between teams.	Use Cases are written to be understood by both the client and the technology team. They represent a written contract of the desired functionality.
Completeness	User Stories are intentionally written at a goal level initially with just enough detail to describe the user story with just a few sentences at most. Only once the iteration planning begins and more detail will be required the team has conversations to capture acceptance tests.	Use Cases are completed in their entirety early in the analysis and design process. Because of this there exists a natural urge by the customers to place screen specific elements in the use cases themselves, even though there is usually a very strong push by the technology team to try and avoid this. Inevitably the technology team rarely succeeds in keeping UI features out of the use cases.
Longevity	Typically User Stories are not intended to live beyond the iteration in which they are developed. Once the functionality has been developed they are discarded.	Use Cases are often saved and become permanent artifacts representing a permanent contract between the customer and development team.

--
Chris Adams
LinkedIn Profile

Describe the V-Model

Chris Adams — Sun, 13 Sep 2015 19:27:00 GMT

The V-Model is essentially an extension of the waterfall model. The system design and development stages of Requirements Gathering through Coding are shown as the downward sloping left side of a “V”, with the Testing stage being broke into its constituent phases of Unit Testing, Integration Testing, System Testing, and User Acceptance Testing creating the upward sloping right side of the “V”. Each system design and development stage on the left corresponds with a testing stage on the right. Each phase of testing is planned in parallel with each of the corresponding system design and development stages to ensure that the appropriate effort and attention is allocated.

What is a SCRUM backlog?

Chris Adams — Thu, 06 Feb 2014 20:32:00 GMT

There are two types of backlogs in SCRUM that are similar in structure, but differ in purpose and level of detail.

The product backlog lists the requirements for the project in the form of user stories, prioritized by highest customer value. It is managed by the product owner, and is updated over the course of the project as requirements are gathered and refined. It contains sufficient detail for the project team to provide relative estimates to develop, typically based on story points. The product backlog is generally updated on a weekly basis.

At the beginning of each sprint, the team reviews the prioritized product backlog and identifies the customer's highest‐priority user stories that can be completed within the sprint period. These stories become the sprint backlog for that particular sprint. The product backlog is created once and maintained over the life of the project; whereas a new sprint backlog is created at the start of each sprint. The sprint backlog is managed by the project team, and contains a detailed list of all the tasks that the team must complete for the user stories in the sprint. The sprint backlog is reviewed and updated on a daily basis.

--
Sandy Lambert
Business Architect
LinkedIn Profile

Should user stories be created to plan for system maintenance and support?

Chris Adams — Thu, 06 Jun 2013 05:07:00 GMT

This question is likely rooted in a misunderstanding of what agile development is all about. Agile project teams are intended to be assembled for specific projects. Once a certain amount of product planning, backlog planning, and sprint planning takes place, the first sprint kicks off. From that point on, the goal of the agile team is to deliver incremental user value at the end of each sprint and to maximize the velocity at which the team delivers such value (Velocity is just a fancy term for the number of Story Points completed during a sprint, and Story Points are the unit of measure used to size user stories relative to each other).

None of this means that the velocity incorporates all costs associated with developing the features defined by the user stories. Overhead still exists within agile teams. In fact, story points don’t track absolute hours at all. They are intended to show the relative size and complexity of user stories for prioritization and sprint planning purposes.

Typically Project Management and Product Management time is lumped into overhead costs. One major reason for this is that much of the work done by these roles cannot map one to one with user stories. There is a lot of project management work and product management work that occurs which never results in value to the user. For example, a product manager may document or lead the effort to create a series of user stories that, once estimated, end up being prioritized out of existence. Perhaps the decision is made that there isn’t enough value in the user stories to have them developed. So this is one example where the time spent by people who work on or with the agile project team isn’t tracked by a user story.

So back to our original question, should distinct user stories be created for maintenance and support. The short answer is no. Once a system or application is developed, there will continue to be hardware and infrastructure management that needs to occur. Someone needs to monitor server loads, bring new virtual servers online when system load rises to a point where server degradation begins to occur, etc.

The slightly longer answer is that while user stories should never be created solely for system support or maintenance, support and maintenance tasks can sometimes be sized into new user stories when it makes sense. If it’s known in advance that a feature defined within a user story is going to require a significant amount of infrastructure to support the new functionality, then the time require to set up and configure new servers should be included in the user story estimate. Of course, it may make sense to distribute this time over several user stories that require the new back end resources. So, really it depends on whether the work is a result of the user story itself.

It’s also worth noting that refactoring is a natural and necessary part of agile development. Refactoring describes the act of restructuring the internal structure of existing code without impacting the external functions of the system as viewed by the user. Refactoring may be needed to improve non-functional aspects of a system such as response times, or refactoring may be required to support a new feature that can’t be supported with the current architectural structure. In agile projects, refactoring is expected and should be planned for. The incremental cost of refactoring should be spread across the impacted user stories whenever possible. User stories contain acceptance tests that need to be retested once the refactoring occurs to ensure that the existing functionality hasn’t been broken.

What is OOAD?

Chris Adams — Sun, 09 Sep 2012 16:25:00 GMT

The acronym OOAD stands for Object Oriented Analysis and Design. OOAD is a software engineering approach that models and designs a system as a group of interacting objects. Object is the term used to describe some entity or “thing” of interest. These objects are typically modeled after real world entities or concepts. For the business analyst, these would be the real-world entities that arise within the business (invoice, product, contract, etc).

Objects have attributes which can be set to specific values. This defines the state of the object. Objects also have methods or functions which define their behavior.

Here is a quick example for illustrative purposes. Consider the real world object “Car”. Our car has attributes that can be defined with specific values such as,

make = ford
model = escape
year = 2002
color = green
maximum speed = 130 mph
current speed = 50 mph
ideal tire pressure = 35 psi
current tire pressure = 31 psi
remaining fuel = 12 gallons

Each of these attributes define the “state” of the vehicle. They describe the car as it is at some point in time. Additionally, the car has certain “behaviors” such as

accelerate ()
decelerate ()
refuel ()
fill tires ()

Each of these behaviors of the real world object can be represented as a method of the object when designing the system (methods are also known as a functions in some programming languages). These methods can change the values of the attributes causing a change in state.

OOAD is comprised of two parts:

(1) object oriented analysis

(2) object oriented design

Models of different types can be created to reflect the static structure, dynamic behavior, and run-time deployment of the collaborating objects of a system.

During the object-oriented analysis (OOA) phase object-modeling techniques are used to analyze the functional requirements for a system and create models which reflect the logical design of the system. During the object-oriented design (OOD) phase of the system, models are elaborated upon to include implementation specific details that show how the physical design of the system will come together. OOA focuses on what the system does (its static structure and behavior), OOD on how the system does it (it’s run-time implementation).

What is the Scrum method?

Chris Adams — Sun, 11 Jul 2010 19:23:00 GMT

Scrum is one of several light-weight agile methods that use an iterative and incremental approach for the development of information systems. The Scrum method brings a small team together to work on a specified set of features over a period of usually 30-days or so (called a sprint).

Both the term Scrum and sprint are borrowed from the sport Rugby. A scrum is where the two teams are engaged in a huddle to begin play following a period where play has been stopped. The fast moving period of play from the point of the scrum until play ends again is called a sprint.

The Scrum method starts each sprint with a kickoff meeting (a period where the entire team comes together). The kickoff meeting lasts a full day and the features of the system to be developed are discussed. The outcome of the kickoff meeting is a set of features that will be developed over the sprint along with estimates of how long the analysis and development of each feature will take.

In order for a feature to be considered completed, it needs to be Analyzed, Designed, Coded, Tested, Refactored, and Documented. If this life-cycle is not fully accomplished during the sprint, perhaps due to an initial underestimation of the time required, the feature will be pushed to a later sprint.

Following the kickoff meeting, and throughout the duration of the sprint, each day is started with a short meeting lasting approximately 15 minute called a daily scrum meeting (also called a daily stand-up meeting). The purpose of this meeting is for the team to discuss what they accomplished the day before, what they will accomplish over the coming day, and to raise any obstacles that they have encountered that may impede progress.

One aspect of Scrum, that is intended to keep the Scrum team and method very agile, is its size. Most Scrum teams consist of no more than about 7 people with each falling into 1 of 3 roles.

Product Owner – identifies the features that will be included in the next sprint and set the priority of each. This is typically a high-level stakeholder in organizations where a true Product Manger/Product Owner role doesn’t exist.
Scrum Master – acts much like the project manager. While the Scrum Master does not micro-manage the teams deliverables, this person ensures that the sprint is on track and enforces the key rules that guide Scrum such as; no new features can be added to the sprint once it is kicked off, and team members cannot be pulled off to work on other side project in the middle of a sprint.
Team Member – unlike traditional software development methods, in Scrum there is little separation of duties between team members. Each team member may fill the role of analyst, designer, coder, tester, and documentation writer.

What is a Requirements Traceability Matrix?

Emy — Thu, 24 Jan 2008 05:06:00 GMT

First of all, let’s talk about requirements traceability in general. Requirements traceability is the ability to follow and audit the life of a requirement, in both a forward and backward direction: from its origins, through its realization in the design and functional specifications, to its eventual development and deployment and use, and through subsequent rounds of modification and refinement.

A Requirements Traceability Matrix is just one method of performing and maintaining requirements traceability.

A good Requirements Traceability Matrix template or any other robust method for managing requirements traceability for a project can answer a variety of questions and solve numerous problems such as:

How was a specific requirement implemented?
What pieces of code will potentially be impacted by modifying a given requirement?
Which test cases are used to verify what requirements?
If I change a specific feature in the application what are the requirements which need to be looked at for impact?
What are all the places in the system where a given piece of data is being used?
etc.

--
Chris Adams
LinkedIn Profile

What is Joint Application Development (JAD)?

Adrian M. — Sat, 10 Nov 2007 06:58:00 GMT

JAD stands for Joint Application Development. JAD is a requirements-definition and software system design methodology in which stakeholders, subject matter experts (SME), end-users, business analysts, software architects and developers attend collaborative workshops (called JAD sessions) to work out a system's details.

The JAD approach, in comparison with more traditional practices, is thought to lead to faster development times and greater client satisfaction, because the client is involved throughout the development process

The focal point of the JAD process is the series of JAD sessions that are attended by stakeholders, executives, SME’s, end-users, business analysts, software architects and developers. It is essential that the roles, responsibilities, and rules for the JAD sessions are well defined and communicated in advance to all participants.

Some typical roles found in a Joint Application Development (JAD) session include:

Facilitator – 1 (only one) - usually a Senior Business Analyst - facilitates discussions, enforces rules,

Scribe – 1 or 2 – sometimes more junior BAs – take meeting notes and clearly document all decisions,

End users – 3 to 5, attend all sessions,

Technical Experts – 1 or 2, question for clarity and give feedback on technical constraints,

Tie Breaker – Senior manager (executive) - breaks end user ties, usually doesn’t attend,

SMEs - Subject Matter Experts,

Observers – 2 or 3 - junior BAs, testers, etc. - do not speak.

Name a few of the industry standards, methodologies, or best practices used by business analysts and systems analysts?

Chris Adams — Thu, 20 Sep 2007 00:57:00 GMT

-UML

-BPMN

-RUP